Reducing process resources incurred by a user interface

ABSTRACT

This document describes techniques and apparatuses for limiting processing resources incurred due to refreshing a user interface. In various embodiments, an event is received, and it is determined whether a delay time period has elapsed. A length of the delay time period is based on a timing of receipt of one or more previous events. If the delay time period has not elapsed, refreshing of the user interface is postponed. When the delay time period elapses, the user interface is refreshed to display an indication of the event.

RELATED APPLICATIONS

This application is a continuation of and claims priority under 35U.S.C. § 120 to U.S. patent application Ser. No. 13/711,039, filed onDec. 11, 2012, and U.S. patent application Ser. No. 12/653,771, filed onDec. 17, 2009, now U.S. Pat. No. 8,345,600, and 35 U.S.C. § 119 or 365to Great Britain, Application No. 0912507.1, filed Jul. 17, 2009, thedisclosures of which are incorporated by reference herein in theirentirety.

BACKGROUND

Some communication systems allow the user of a device, such as apersonal computer, to communicate across a packet-based computer networksuch as the Internet. Such communication systems include voice overinternet protocol (“VoIP”) systems. These systems are beneficial to theuser as they are often of significantly lower cost than conventionalfixed line or mobile networks. This may particularly be the case forlong-distance communication. To use a VoIP system, the user installs andexecutes client software on their device. The client software sets upthe VoIP connections as well as providing other functions such asregistration and authentication. In addition to voice communication, theclient may also set up connections for other communication media such asvideo calling, instant messaging (“IM”), SMS messaging, file transferand voicemail.

One type of communication system for packet-based communication uses apeer-to-peer (“P2P”) topology. To enable access to a peer-to-peersystem, a user must execute P2P client software provided by a P2Psoftware provider on their computer, and register with the P2P system.When the user registers with the P2P system, the client software isprovided with a digital certificate from a server. Once the clientsoftware has been provided with the certificate, then calls or othercommunication connections can subsequently be set up and routed betweenusers of the P2P system without the further use of a server in theset-up. Instead, the client looks up the required IP addresses frominformation distributed amongst the P2P client software on other endusers' computers within the P2P system. That is, the address look-uplist is distributed amongst the peers themselves. Once the IP address ofa callee's terminal has thus been determined, the caller's P2P clientsoftware then exchanges certificates with the callee's P2P clientsoftware. The exchange of the digital certificates (or user identitycertificates, “UIC”) between users provides proof of the users'identities and that they are suitably authorized and authenticated inthe P2P system. Therefore, the presentation of digital certificatesprovides trust in the identity of the users.

It is therefore a characteristic of peer-to-peer communication that,once registered, the users can set up their own communication routesthrough the P2P system in an at least partially decentralized mannerbased on distributed address look-up and/or the exchange of one or moredigital certificates, without using a server for those purposes. Furtherdetails of an example P2P system are disclosed in WO 2005/009019.

VoIP or other packet-based communications can also be implemented usingnon-P2P systems that do use centralized call set-up, e.g. via server.

Sometimes software programs such as communication clients must respondto asynchronous events, specifically state and/or data changes due toexternal events such those that occur over a network. To convey theseevents to the end user, the program must refresh one or more userinterface elements on screen. “Refresh” in this context means theprocess of reading a new data value and then redrawing the value in someuser interface element on screen. Example: user A is chatting with userB. When user B sends data or goes offline, such changes must be shown byrefreshing the user interface element corresponding to user B on userA's screen.

The most simplistic method is to refresh the user interface directly inresponse to receiving an indication of such an event. This works well inthe common case, but if the rate of incoming event indications is veryhigh then the user interface will be needlessly refreshed too often,causing a performance problem.

SUMMARY

According to one aspect, there is provided a method for limitingprocessing resources incurred due to refreshing a user interface of afirst terminal, the method comprising: at a first terminal, receiving aplurality of event indications which indicate respective events, each ofthe event indications being received at a different time; and based onthe event indications, refreshing the user interface of the firstterminal to reflect each of the respective events; wherein saidrefreshing comprises determining a plurality of time periods, and duringeach of said time periods postponing the user interface from beingrefreshed to reflect any outstanding ones of said event indicationsuntil that time period has elapsed; and wherein said time periods areeach determined having a length set in dependence on a timing of thereceipt of one or more of said event indications, the length of a laterof said time periods being set to an increased value relative to anearlier of said time periods in response to the receipt of one or moreof said event indications within a time limit.

Using this method, the refresh rate is not constant but ratherdetermined relative to the incoming indications of events. For example,when the rate of incoming event indications is low then the userinterface may be refreshed immediately. This provides maximum perceivedresponsiveness. When the rate of incoming event indications is high, therefresh rate may be throttled down. This ensures that the too manyprocessing cycles are not used in refreshing the user interface, e.g. sothat user interface updates do not “steal cycles” from other processingrequired in relation to the events.

In embodiments, said event indications indicate respective eventsoccurring externally to the first terminal.

The method may be a method of limiting processing resources incurred dueto refreshing a user interface of a first terminal in a communicationsystem for communicating between the first and other terminals via apacket-based network; and the receipt of said event indications maycomprises: at the first terminal of the communication system, receivinga plurality of event indications signaled over the packet-based networkto indicate respective events occurring in relation to one or more ofthe other terminals of the communication system.

The method may comprise receiving further event indications indicativeof events occurring locally at the first terminal, and said time periodsmay be determined in dependence on the timing of receipt of one or moreevent indications indicating either one of an external and a localevent.

The time limit may be the expiry of earlier time period running sincelast refresh of the user interface.

The time limit may be based on a time interval between the receipt oftwo event indications.

The event indications may be received asynchronously with respect to thefirst terminal.

Said refreshing may comprise, during at least one of said time periods,postponing the user interface from being refreshed to reflect anoutstanding plurality of said event indications until that time periodhas elapsed, such that following said time period the user interface isrefreshed to reflect the plurality of outstanding event indications inthe same refresh operation.

Said time periods may each be determined having a length set accordingto a substantially exponential back-off process, whereby the length ofthe later time period is multiplied by a predetermined factor relativeto the earlier time period in response to receipt of one or more of saidevent indications within said time limit.

The method may comprise constraining the length to being set within amaximum cap value.

The length of the later time period may be increased unless fewer than apredetermined number of said event indications are received during theearlier time period. The length of the later time period may beincreased unless none of said event indications are received during theearlier time period.

The length of the later timer period may be reset to a lower value iffewer than a predetermined number of event indications are receivedduring the earlier time periods. The length of the later time period maybe reset if none of said event indications are received during theearlier time period.

If at least a predetermined number of said event indications arereceived within the earlier time period running since the last refresh,then next refresh of the user interface may be postponed until theearlier time period has elapsed and the length of the later time periodmay be increased, the later time period running from the next refresh.

If fewer than a predetermined number of said event indications arereceived within the earlier time period running since the last refresh,then the next refresh of the user interface may not be postponed and thelength of the later time period running from that next refresh may bereset to a lower value.

If any of said event indications arrives within the earlier time periodrunning since the last refresh, then the next refresh of the userinterface may be postponed until the earlier time period has elapsed andthe length of the later period running from that next refresh may beincreased.

If none said event indications arrives within the earlier time periodrunning since the last refresh, then the next refresh of the userinterface may not be postponed and the length of the later time periodrunning from that next refresh may be reset to a lower value.

Said time periods may be determined according to the following process:

at program initialization, set a delay to an initial value, the delaybeing a variable setting the lengths of said time periods;

upon receiving one of said event indications:

-   -   (a) calculate a time difference between a current clock time and        a time of last refresh;    -   (b) if the time difference is greater than the delay:        -   (i) perform the user interface refresh and save the current            clock time as the time of last refresh,        -   (ii) reset the delay to the initial value;    -   (c) if the time difference is less than the delay:        -   (i) if there is no current refresh timer then schedule a            refresh timer to fire at the last refresh time plus the            delay,        -   (ii) if there is already a current refresh timer then do not            schedule another refresh timer;        -   when the refresh timer fires:    -   (d) perform the user interface refresh and save the current        clock time as the time of last refresh;    -   (e) multiply the delay by a predetermined factor.

Although the processing cost of a refresh operation may be less of aproblem for higher performance desktop or laptop PCs, it may start tobecome a particular problem with the rise of VoIP communicationsimplemented on internet-enabled mobile phones, where processingresources are more limited.

Therefore in one embodiment: the first terminal may be a mobileterminal, and said communication system may be a VoIP system, the mobileterminal being installed with a VoIP client for communicating with theother terminals via a mobile cellular network and the internet; thereceipt of the event indications may comprise receiving the eventindications via the internet and mobile cellular network; and therefreshing may comprise refreshing a user interface of the VoIP client.

According to another aspect, there is provided a program product forlimiting processing resources incurred due to refreshing a userinterface of a first terminal, the program comprising code embodied on acomputer-readable medium and being configured so as when executed on thefirst terminal to: receive a plurality of event indications whichindicate respective events, each of the event indications being receivedat a different time; and based on the event indications, refresh theuser interface of the first terminal to reflect each of the respectiveevents; wherein said refreshing comprises determining a plurality oftime periods, and during each of said time periods postponing the userinterface from being refreshed to reflect any outstanding ones of saidevent indications until that time period has elapsed; and wherein saidtime periods are each determined having a length set in dependence on atiming of the receipt of one or more of said event indications, thelength of a later of said time periods being set to an increased valuerelative to an earlier of said time periods in response to receipt ofone or more of said event indications within a time limit.

The program product may comprise further code configured to perform anyof the additional method steps described herein.

According to another aspect, there is provided a first terminalcomprising: a receiver configured to receive a plurality of eventindications which indicate respective events, each of the eventindications being received at a different time; a screen for displayinga user interface; and processing circuitry, coupled to the receiver andscreen, configured to refresh the user interface based on the eventindications to reflect each of the respective events; wherein theprocessing circuitry is configured to generate a plurality of timeperiods, and during each of said time periods to postpone the userinterface from being refreshed to reflect any outstanding ones of saidevent indications until that time period has elapsed; and the processingcircuitry is configured to generate each of said time periods having alength set in dependence on a timing of the receipt of one or more ofsaid event indications, the length of a later of said time periods beingset to an increased value relative to an earlier of said time periods inresponse to receipt of one or more of said event indications within atime limit.

The processing circuitry may be further configured in accordance withany of the methods described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the various embodiments and to show how itmay be carried into effect, reference will now be made by way of exampleto the accompanying drawings in which:

FIG. 1 is a schematic representation of a packet-based network such asthe Internet.

FIG. 2 is a schematic block diagram of a user terminal installed with aweb-client application and P2P client application.

FIG. 3 is a schematic representation of a P2P client application userinterface viewed on a user terminal.

FIG. 4 is a timeline showing an example operation of a UI refreshback-off algorithm.

DETAILED DESCRIPTION

FIG. 1 is a schematic illustration of a packet-based network such as theInternet, which comprises a plurality of interconnected elements such asthose labeled 102, 104, 105 and 106. Each network element isinter-coupled with the rest of the Internet 108, and is configured tocommunicate data with other such elements over the Internet bytransmitting and receiving data in the form of Internet Protocol (IP)packets. Each element also has an associated IP address locating itwithin the Internet. The elements shown explicitly in FIG. 1 are: aplurality of end-user terminals 102(A) to 102(E) such as desktop orlaptop PCs or Internet-enabled mobile phones; one or more P2P servers104; one or more web servers 105; and a gateway 106 to another type ofnetwork 109 such as to a traditional Public-Switched Telephone Network(PSTN) or other circuit switched network, and/or to a mobile cellularnetwork. However, it will of course be appreciated that many moreelements make up the Internet than those explicitly shown. This isrepresented schematically in FIG. 1 by a communications cloud 108 whichwill include many other end-user terminals, servers and gateways, aswell as routers of Internet service providers (ISPs) and Internetbackbone routers.

Each of a plurality of the end-user terminals 102 is installed withcommunication software in the form of a P2P client application. Whenexecuted, this allows the end-user terminals 102 to establishbidirectional communication channels with other such end-user terminals102 via the Internet using P2P call set-up (or more generally connectionset-up). The P2P client applications also share presence informationwith one another, which provides an availability status of users. Thepresence information for each user can be at least in part defined bythe user themselves. To supplement the decentralized call set-up, theP2P client application may retrieve some additional information from theP2P server 104, such as contact lists which provide the names and userIDs of the users' contacts, “avatars” which are images chosen by usersto represent themselves within the P2P system.

There may also be a P2P client application installed at one or moregateways 106 coupled to both the Internet 108 and one or more othernetworks 109 such as a PSTN network and/or a mobile cellular network.This allows the P2P client applications running on end-user terminals102 to communicate with ordinary land-line telephones and/or mobiletelephones respectively, even if those telephones themselves do not runP2P client applications and are not directly coupled to the Internet. Inthat case, the P2P client application on the terminal 102 sets up aconnection over the Internet with the P2P client application on thegateway 106 using P2P call set-up and provides it with a phone number,and the gateway 106 uses the phone number to set up a connection withthe telephone over the respective other network. Or in the otherdirection, a telephone user may dial into the gateway 106 with a numberthat identifies the user within the P2P system, and the gateway 106 willset up a connection with that user's terminal 102 over the Internet. Ineither case, a bidirectional communication channel can thus beestablished via the Internet and PSTN or mobile cellular network.

Each of the end-user terminals 102 may also be installed with otherInternet-related software such as a web browser which, when executed,allows the user terminal 102 to retrieve information in the form of webpages from web servers 105 coupled to the Internet 108.

The schematic block diagram of FIG. 2 shows an example of an end-userterminal 102, which is configured to act as a terminal of a P2P systemoperating over the Internet. The terminal 102 comprises a processor orCPU 200 operatively coupled to: a network interface 202 such as modemfor connecting to the Internet 108, a non-volatile storage device 204such as a hard-drive or flash memory, and a volatile memory device suchas a random access memory (RAM) 206. The terminal 102 also comprises oneor more user input devices, for example in the form of a keyboard orkeypad 210, a mouse 208, a microphone 216 and a webcam 218, eachoperatively coupled to the CPU 200. The terminal 102 further comprisesone or more user output devices, for example in the form of a displayscreen 208 and speaker 214, again each operatively coupled to the CPU200.

The storage device 204 stores software including at least an operatingsystem (OS) 220, and packet-based communication software in the form ofa P2P client application 222. The storage device may also store otherInternet-related software such as a web-browser 221. On start-up orreset of the terminal 102, the operating system software 220 isautomatically loaded into the RAM 206 and from there is run by beingexecuted on the CPU 200. Once running, the operating system 220 can thenrun applications such as the web client application 221 and P2P clientapplication 222 by loading them into the into the RAM 206 and executingthem on the CPU 200. To represent this schematically in FIG. 2, theoperating system 220, web client application 221 and P2P clientapplication 222 are shown within the CPU 200.

The P2P client application 222 comprises a “stack” having three basiclayers: an input and output (I/O) layer 224, a client engine layer 226,and a user interface (UI) layer 228. Each layer is responsible forspecific functions. Because each successive layer usually communicateswith two adjacent layers (or one in the case of the top layer), they areregarded as being arranged in a stack as shown in FIG. 2. The web clientapplication 221 and P2P client application 222 are said to be run “on”the operating system 220. This means that in a multi-tasking environmentthey are scheduled for execution by the operating system 220; andfurther that inputs to the web client application 221 and the lowest(I/O) layer 224 of the P2P client application 222 from the input devices202, 216 and 218 as well as outputs from web client application 221 andthe I/O layer 224 of the P2P client application 222 to the outputdevices 202, 208 and 214 may be mediated via suitable drivers and/orAPIs of the operating system 220.

The I/O layer 224 of the P2P client application comprises audio and/orvideo codecs which receive incoming encoded streams and decodes them foroutput to speaker 214 and/or display 208 as appropriate, and whichreceive unencoded audio and/or video data from the microphone 216 and/orwebcam 218 and encodes them for transmission as streams to otherend-user terminals 102 of the P2P system. The I/O layer 224 may alsocomprises a control signaling protocol for signaling control informationbetween terminals 102 of the network.

The client engine 226 then handles the connection management functionsof the P2P system as discussed above, such as establishing calls orother connections by P2P address look-up and authentication. The clientengine may also be responsible for other secondary functions of the P2Psystem such as supplying up-to-date contact lists and/or avatar imagesof the user to the P2P server 104; or retrieving up-to-date contactlists of the user and retrieving up-to-date avatar images of other usersfrom the P2P server 104. Further, the client engine may retrievepresence information from the other clients of the users in the contactlist by periodically polling them via a public API, and reciprocallyprovide its own presence information when polled by those other clientsthat are online. In some cases, the presence information can beexchanged directly between clients via a public API, but alternativelythe presence information could be exchanged via an intermediate nodesuch as a server 104.

The UI layer 228 is responsible for presenting decoded video to the uservia the display 208, for presenting the output on the display 208 alongwith other information such as presence and profile information and usercontrols such as buttons and menus, and for receiving inputs from theuser via the presented controls.

FIG. 3 illustrates schematically an example user interface as would bepresented to a user on the display 208 when the P2P client application222 is open for viewing by the user. In this example, the user interface228 is that of the P2P client application 222 running on a first userterminal 102(A). The user interface is divided into a number of panels.A first panel 302 displays some details of the user's own profile, inthis example the user's name “Joe Everyman”, an avatar image, and a“mood message”. These details may be stored at and retrieved from theP2P server 104 by the client engine 226, so as to be made available toother users of the P2P network. The avatar image is an image chosen bythe user to represent themselves to other users (which need notnecessarily be a photo of themselves). The mood message is a briefuser-defined statement which can be used for any purpose but istypically used to express how the user is feeling, news about recentevents in the user's life, or any upcoming plans that may affect theuser's availability (the mood message may therefore in some cases beconsidered a type of presence information). When other users view Joe'sprofile in their own clients, these details will be visible to them viathe P2P server 104, and vice versa the other users' details will be madeavailable to Joe's client (if they are in each other's contact lists).

A second panel 304 of the user interface displays a contact list of theuser's friends or associates, these being other users of the P2Pnetwork. Entry in the contact list can be conditional on agreement fromthe users. The contact list may be stored at and retrieved from the P2Pserver by the client engine 226, so that the same list is available tothe user uses different instances P2P client application on differentterminals. Presence information is also displayed in the panel next toeach contact. The presence information represents an availability statuswhich can comprise an indication of whether the user is online, and canbe in part user-defined. For example, the presence status may be: theuser is offline (×), the user is online and has selected to be shown asavailable (√), or the user is online but has selected to be shown as notavailable (−).

A third panel 306 of the user interface displays the profile of aselected user from the contact list, in this case “Stephen Madeup”, auser of another user terminal 102(B). The displayed profile includesStephen's name, avatar image and mood message, along with other detailsStephen may have supplied to the P2P server 104 such as currentlocation, local time, gender and date of birth (DOB). These profiledetails are retrieved from the P2P server 104 by the client engine 226.

A fourth panel 308 of the user interface then displays communicationcontrols in relation to the selected contact, such as buttons allowing avoice or video call to be established, and a window for entering chatmessages. Any incoming chat messages and chat history will be displayedin this panel also, and file transfers may be established bydragging-and-dropping files into the chat window.

As mentioned, the user interface displayed on the screen 208 of a userterminal such as 102(A) will often need to be refreshed in order toreflect events occurring in relation to other, remote terminals of thenetwork, such as other user terminals 102(B . . . E). Indications ofthese events are signaled to the I/O layer 224 via the network 108. Ifan event relates to another user terminal 102(B . . . E), then theindication of that event may be signaled either from the other userterminal itself or from a server 104 that has information about thatother user terminal. Based on the received indications, the UI layer 228then handles the refreshing of user interface to reflect thecorresponding events.

The events typically do not occur in any particular synchronized manner,and so the event indications typically arrive asynchronously withrespect to the receiving user terminal 102(A). That is to say, theyarrive at no particular predictable or regular time from the perspectiveof the receiving terminal 102(A).

Examples of such events are as follows. By way of example, these will bedescribed in terms of a receiving user terminal 102(A) refreshing itsuser interface based on indications of events occurring in relation to aremote user terminal 102(B), but it will be understood that events canbe signaled between any terminals.

One type of event occurs when a remote user's presence has changed, e.g.that user has gone on or off line or has chosen to be shown asunavailable (“do not disturb”). In that case the indication of the eventis signaled directly between the users' terminals 102(A) and 102(B) overthe network 108, but could alternatively be signaled via a server 104 ora relaying user terminal such as 102(C). Based on the receivedindication, when the UI layer 228 refreshes the user interface it mayfor example alter a presence icon such as (×), (√), or (−) displayed inco-location with the remote user's name in the contact list 304 orprofile 306.

Another type of event occurs when a remote user's profile informationhas changed, e.g. the remote user has changed their avatar image or moodmessage. In that case the indication of the event is signaled to thereceiving user terminal 102(A) from the server 104 where the profileinformation of the remote user is stored, in response to the changeduploaded from the remote user terminal 102(B). Alternatively however,the indication of the event could be signaled directly between theusers' terminals 102(A) and 102(B) or via a relaying user terminal suchas 102(C). Based on the received indication, when the UI layer 228refreshes the user interface it will alter the displayed profile 306accordingly.

Another type of event occurs when there is call activity in relation toa voice or video call. E.g. if the remote user has initiated a call withthe receiving user terminal 102(A) or has terminated the call. In thatcase the indication of the event is signaled directly between the users'terminals 102(A) and 102(B) over the network 108, but couldalternatively be signaled via a server 104 or a relaying user terminalsuch as 102(C). Based on the received indication, when the UI layer 228refreshes the user interface it may for example display a message oranimation in the profile 306 or communication panel 308 notifying thereceiving user that the remote user is calling them or has just hung up,or such like.

Another type of event occurs when the remote user terminal 102(B) sendsdata to the receiving user terminal 102(A), e.g. a chat message which isto be displayed on a screen, or a file transfer whose initiation, statusor progress must be indicated on the screen. In that case the indicationof the event is again signaled directly between the users' terminals102(A) and 102(B) over the network 108, but could alternatively besignaled via a server 104 or a relaying user terminal such as 102(C).Based on the received indication, when the UI layer 228 refreshes theuser interface it may for example display a message notifying thereceiving user of the incoming transfer or its status, or display apercentage or progress bar notifying of the progress of the transfer.

In relation to an IM chat session, yet another type of event may occurif the client applications of the receiving and remote terminal 102(A)and 102(B) support a “typing indicator” feature. The typing indicatorprovides a notification to the receiving user that the remote user iscurrently typing. E.g. a visual animation such as a scribbling pencilmay be displayed in the communication panel 308 based on an indicationreceived at the receiving terminal 102(A) to indicate the event that theremote user is typing. The indication may also indicate the kind oftyping activity, e.g. so that the displayed notification distinguishesbetween the typing of words and pressing the delete key. The typingindicator helps avoid confusion that could otherwise be caused bycrossed chat messages. In the case of the indication of chat activity,the indication of the event is signaled directly between the users'terminals 102(A) and 102(B) over the network 108, but couldalternatively be signaled via a server 104 or a relaying user terminalsuch as 102(C).

Another type of event is a history event such as a missed call or anavailable voicemail. In that case the indication of the event issignaled to the receiving user terminal 102(A) from the server 104 wherethe information about the missed call or voicemail is stored, inresponse to the attempted call from the remote user terminal 102(B).Alternatively however, the indication of the event could be signaleddirectly between the users' terminals 102(A) and 102(B) or via arelaying user terminal such as 102(C). Based on the received indication,when the UI layer 228 refreshes the user interface it will insert anotification of the missed call or voicemail somewhere appropriate inthe user interface.

At any time, various different indications of any of these or othertypes of events may be arriving at the receiving terminal 102(A)asynchronously, and furthermore some may arrive within a short space oftime of each other. If the user interface has to be refreshedstraightaway every time an indication of a new event arrives, then alarge number of processing cycles may be incurred by repeatedly updatingthe user interface.

The inventor has identified two particular situations where such eventscan tend to cause performance problems. The first is on launch of theclient (especially first launch), when the contact list is synchronizedand many “property changed” indications are received. The second alsooccurs on launch (especially first launch), when chats and chat messagesare synchronized. E.g. if the user has been using chat on one device andthen switches to another device, he or she might log in and receivehundreds if not thousands of chat messages when the client syncs.

However, more generally, it will be appreciated that the describedperformance problem can occur in any situation where multiple eventindications arrive.

To try to solve this, the idea is that if the events are close enoughtogether in time then the refreshing of the user interface to reflectone or more of them can be postponed without the user perceiving asignificant lack of responsiveness. If a refresh operation involvesrefreshing a part of the user interface reflecting multiple events (oreven the whole user interface), then this may mean that one or moreoutstanding events can be “saved up” and then multiple events handled inthe same refresh operation. Because the refresh operations may involveanimations or other significant transitions (such as re-sorting thecontact list or auto-scrolling to the newest chat messages), it isadvantageous to collect multiple changes into a single operation so thedisplay and processor are not encumbered with multiple successiverefresh operations. E.g. otherwise this could cause the screen to flitfrom one update to another which would be distracting for the user andmake the user interface awkward to use. But even if different elementsof the user interface are refreshed separately to reflect individualrespective events, then there may still be a performance advantage inpostponing a refresh until a later time when there are fewer otherrefresh operations or other processing operations relating to thehandling of the events themselves such as data processing operations.For example, postponing the refresh can also be advantageous so that theprogram remains responsive in case the user is trying to scroll, type,etc. during this time.

As mentioned, there are some existing solutions. Nonetheless, it wouldstill be desirable to try to optimize the trade-off between theresponsiveness of the user interface and the number of processing cyclesused refreshing that user interface.

According to some embodiments, the improved solution is toalgorithmically determine the period of time during which refreshes arepostponed, based on the receipt of incoming event indications. Analgorithm for increasing such a time period may be referred to herein asa “back-off” algorithm. The algorithm may have the effect that a greaterrate of incoming events tends to result in a greater time period. Forexample, the algorithm may have the effect that when the rate ofincoming events is low then the user interface will be refreshedimmediately. This provides maximum perceived responsiveness. When therate of incoming events is high however, the refresh rate may bethrottled down. This ensures that the user interface updates do notdivert processing cycles from other processing that may be required atthe receiving terminal 102(A), either in relation to handling the eventsor otherwise.

The back-off algorithm works by setting a plurality of time periodsduring which refreshes are postponed. These may be referred to herein asdelay periods, and each can be measured from a respective time of lastrefresh. Any event indication that is received within such a delayperiod does not result in the user interface being refreshedimmediately, but instead the user interface is only refreshed to reflectall outstanding event indications once the delay period has elapsed.

The back-off algorithm can operate such that the length of the delayperiod is increased between an earlier to a later time period unless noevent indications are received during the earlier time period. Further,the length of the delay period can be reset to some lower value if noindications are received during one of the delay periods.

According to one embodiment, the algorithm can be summarized by thefollowing statement: if an indication of an event arrives within thecurrent delay period running since the time of last refresh, then therefreshing of the user interface to reflect that event is postponeduntil that delay period has elapsed, and the next delay period runningfrom that refresh will be increased in length; but otherwise, if anindication of an event arrives only after the delay period since thetime of last refresh, then there is no need to postpone the refreshingof the user interface when the next event does arrive and the length ofthe next delay period running from the next refresh will be reset.

Optionally, the increase and/or resetting of the length of the delayperiod need not necessarily be based on whether no events at all werereceived within the delay period. Alternatively, one or both of theseactions could be based on whether there were fewer than a predeterminednumber of events received within that period.

The algorithm can be a substantially exponential back-off algorithm,whereby the length of the next delay period is multiplied by a factor inresponse to asynchronous incoming events. In embodiments themultiplication is applied when the last delay period has elapsed and theuser interface refreshed, and at least one event indication was receivedduring that last delay period.

In some implementations, a maximum cap may be applied to the delay sothat even during a steady stream of incoming events, the user interfaceis still updated somewhat periodically.

An example back-off algorithm is now described.

-   -   At program initialization, set the delay to a small constant        value, e.g. 0.1 seconds.    -   Upon receiving an incoming indication of an event:        -   (a) Calculate the time difference between the current clock            time and the time of the last refresh.        -   (b) If the time difference is greater than the delay:            -   (i) Perform the user interface refresh immediately, and                save the current clock time.            -   (ii) Reset the delay to the initial value.        -   (c) If the time difference is less than the delay:            -   (i) If there is no current refresh timer, schedule a                one-shot timer to fire at the last refresh time+the                delay.            -   (ii) If there is a current refresh timer, do nothing.                The timer will handle the refresh at the scheduled time.    -   When the refresh timer fires:        -   (d) Perform the user interface refresh immediately, and save            the current clock time.        -   (e) Multiply the delay by a fixed factor, e.g. 2.

An example operation of this algorithm is set out in the example below,and also illustrated in the timeline of FIG. 4.

Time Description [00:00:00] Incoming event indication [00:00:00] <--Refresh immediately (Delay=1) [00:00:01] Incoming event indication //timer scheduled for 0:00:02 [00:00:02] <-- Timer refresh (new Delay=2)[00:00:02] Incoming event indication // timer scheduled for 0:00:04[00:00:03] Incoming event indication // ignored [00:00:04] <-- Timerrefresh (new Delay=4) [00:00:04] Incoming event indication // timerscheduled for 0:00:08 [00:00:05] Incoming event indication // ignored[00:00:07] Incoming event indication // ignored [00:00:08] <-- Timerrefresh (new Delay=8) [00:00:09] Incoming event indication // timerscheduled for 0:00:16 [00:00:11] Incoming event indication // ignored[00:00:14] Incoming event indication // ignored [00:00:15] Incomingevent indication // ignored [00:00:16] <-- Timer refresh (new Delay=8) :[00:00:25] Incoming event [00:00:25] <-- Refresh immediately (Delay=1)

In this example, at some time arbitrarily referred to as t=0 an eventindication arrives for the first time since program initialization.There is no defined time of last refresh, so the user interface isrefreshed straightaway. Suppose then that at a subsequent time t=1,another event indication arrives. This is within the initial delayperiod D=1 of the last refresh, and therefore according to the algorithmthe user interface is not refreshed straightaway but instead a refreshtimer is set to fire (actuate) at the initial delay time D=1 plus thetime of last refresh t=1, i.e. at time t=2. When the refresh timer thendoes fire at time t=2, the user interface is refreshed to reflect theevents indicated by the outstanding indications. Also when the refreshtimer fires, the length of the delay period is multiplied by apredetermined factor, in this example 2, thus setting the delay periodto D=2.

Now suppose yet another event indication arrives at time t=2 (but not intime to be included in the refresh scheduled for t=2). This is withinthe new delay period D=2 of the last refresh, and therefore the userinterface is not refreshed straightaway, and a refresh timer isscheduled for the new delay time D=2 plus the time of last refresh t=2,i.e. scheduled for t=4. In the meantime, a further event indication mayarrive at time t=3 but this will also be ignored until the timer firesat time t=4. When the refresh timer then does fire at time t=4, the userinterface is refreshed to reflect the events indicated by bothoutstanding indications. The user interface refresh to reflect theevents indicated by both outstanding indications may be implemented aspart of the same refresh operation, thus saving processor cycles sincetwo separate refresh operations are not required at separate times toreflect each individually. Also when the refresh timer fires, the lengthof the delay period is multiplied again by the predetermined factor 2,thus setting the delay period to D=4.

Now suppose a yet further event indication arrives at time t=4 (but notin time to be included in the refresh scheduled for t=4). This is withinthe new delay period D=4 of the last refresh, and therefore the userinterface is not refreshed straightaway, and a refresh timer isscheduled for new delay time D=4 plus the time of last refresh t=4, i.e.scheduled for t=8. In the meantime, yet more event indications mayarrive for example at times t=5 and t=7 but these will also be ignoreduntil the timer fires at time t=8. When the refresh timer then does fireat time t=8, the user interface is refreshed to reflect the eventsindicated by all three outstanding indications. This refresh of allthree outstanding indications may be implemented as part of the samerefresh operation, thus saving processor cycles since three separaterefresh operations are not required at separate times to reflect eachindividually. Also when the refresh timer fires, the length of the delayperiod is multiplied again by the predetermined factor 2, thus settingthe delay period to D=8.

Now suppose a yet further event indication arrives at time t=9, afterthe refresh performed at t=8. This is within the new delay period D=8 ofthe last refresh, and therefore the user interface is not refreshedstraightaway, and a refresh timer is scheduled for new delay time D=8plus the time of last refresh t=8, i.e. scheduled for t=16. In themeantime, yet more event indications may arrive for example at timest=11, t=14 and t=15 but these will also be ignored until the timer firesat time t=16. When the refresh timer then does fire at time t=16, theuser interface is refreshed to reflect the events indicated by all theoutstanding indications. The length of the delay period would also bemultiplied by 2 again, except in this example the length is capped at amaximum of 8.

Then say for example that no more event indications arrive until a latertime t=25. The delay period expired at t=24 (the time of last refresht=16 plus the delay D=8). Therefore according to the algorithm, the userinterface is refreshed straightaway upon receiving the indication att=25, and the delay period is reset to its lowest value of D=1.

The various embodiments have a particularly advantageous application toan internet-enabled mobile phone. In that case the modem 202 is awireless cellular modem for connecting to the internet via a mobilecellular network. In some embodiments, this is distinct from thesituation described earlier in relation to FIG. 2 whereby a mobile phonenot installed with a VoIP or P2P client is able to still access the VoIPor P2P system via a client application running on the gateway 106.Rather, a client application is installed and run directly on the mobilephone itself. In that case the mobile terminal can be considered one ofthe user terminals 102 shown schematically in FIG. 2, although some kindof gateway to the internet 108 will typically still be involved as partof the mobile network operators' infrastructure.

As mentioned, this is a particularly advantageous application of thedescribed embodiments since the processing cost of a refresh operationmay start to become a particular problem with the rise of VoIPcommunications implemented on internet-enabled mobile phones, whereprocessing resources are more limited than in more conventional PC basedapplications (although the various embodiments can still have a benefitfor PCs or other types of terminal as well).

It will be appreciated that the above embodiments are described only byway of example.

For instance, the above is only an example of a back-off algorithm. Itwill be appreciated given the disclosure herein that any back-offalgorithm could be used whereby the length of time period for which therefresh is postponed increases with some measure of the number, rate ortiming of incoming event indications. For example, instead of measuringthe time between arrival of an event indication and the time of lastrefresh, e.g. as in step (a) above, the algorithm could alternatively oradditionally measure the time interval between the arrival of two ormore event indications and set the delay period in dependence on thatinterval. Or the algorithm could operate by measuring an averageincoming rate Rav of event indications and calculating the length of thedelay period D by a function D=f(Rav), where the form of f may bedetermined by simulation or empirical testing of different trialfunctions.

Also note that “rate” does not necessarily mean a regular rate, but moregenerally can refer to any measure of a number of event indicationsreceived per unit time, during any window of time, whether regular ornot.

During the delay period, it is not necessarily the case that allincoming event indications of all kinds are ignored. Where it isreferred to receiving a plurality of event indications or similar, thiscould refer only to a certain set or type of event indications, andwhere it is referred to postponing the refresh to reflect anyindications this could only mean any indications of that type or set.

Where it is said that an event indication arrives or is received from anexternal source, the receipt or arrival need not necessarily refer tothe immediate capture from the external medium into the terminal.Instead, it may also involve some amount of buffering and/or dataprocessing. That is, the “receipt” or “arrival” of the indication mayactually refer to the meaningful recognition of the indication by thealgorithm in question rather than the physical receipt or arrival. Insome cases for example, when the client is launched after a certaintime, it may receive a plurality of event indications that have beenstored or cached during that time either locally or at a remote terminalsuch as a server. Either way, the indications may still indicateexternal events even though they have been stored for a time beforebeing received by the client's refresh algorithm.

In addition to external events occurring over the network, the algorithmcould also take into account local events such as from those originatingfrom peripherals, e.g. like mouse clicks or keyboard events. These couldoccur for example when the local user changes his or her own presence orprofile information or types a chat message, etc. Though in at leastsome embodiments the algorithm would at least take into account externalevents occurring over the network.

Although the above has been described mainly in terms of a peer-to-peer(P2P) system, the various embodiments are not specific to P2P and may beapplied to any kind of packet-based communications system, such as morethe centralized VoIP systems mentioned previously. Further, the variousembodiments are not limited to use over the Internet, but could beimplemented over any packet-based network.

Further, the various embodiments are not limited only to refreshing auser interface to reflect events signaled over a network or as part of acommunication system. More generally, the various embodiments can beapplied to optimize the refreshing of a user interface to reflect anyexternal event occurring externally to the receiving terminal, or eveninternally.

In various embodiments, the refresh back-off algorithm is implemented bysoftware stored on a general purpose memory such as flash memory or harddrive and executed on a general purpose processor. The software can, butneed not necessarily be integrated as part of the client application.However, alternatively the algorithm could be implemented in firmware oreven in dedicated hardware. The algorithm could be any type of process,e.g. it could comprise a series of conditional steps such as thosedescribed above, and/or an equation like D=f(Rav), and/or it couldcomprise referring to a look-up table.

Other configurations and applications of the various embodiments may beapparent to the person skilled in the art given the disclosure herein.The scope of the claimed subject matter is not limited by the describedembodiments, but only by the appended claims.

What is claimed is:
 1. A computing device comprising: a memory and aprocessor configured to: receive events; control a refresh rate at whicha user interface is refreshed to indicate receipt of the events using arefresh timer, a length of the refresh timer set based at least in parton a rate of incoming events such that, when the rate of incoming eventsis low, the refresh timer length is decreased causing the refresh rateto be increased, and when the rate of incoming events is high, therefresh timer length is increased causing the refresh rate to bedecreased; and refreshing the user interface, in accordance with therefresh rate, to display one or more indications of the events.
 2. Thecomputing device of claim 1, wherein the events are related tocommunication events of a communications application.
 3. The computingdevice of claim 1, wherein the rate of incoming events is calculatedfrom a number of received events in a previous delay time period, adelay time period being a time between consecutive expirations of therefresh timer.
 4. The computing device of claim 3, wherein the memoryand the processor are configured to control the refresh rate by beingconfigured to: store an incoming event in the memory; and cause therefresh of the user interface to display an indication of the incomingevent and any other events stored in the memory since a last refreshupon expiry of the refresh timer.
 5. The computing device of claim 4,wherein the events are related to communications of a communicationsapplication and are received over a communications network.
 6. Thecomputing device of claim 4, wherein the memory and the processor arefurther configured to: adjust a length of the refresh timer for a nextdelay time period based on a number of events received during a currentdelay time period.
 7. The computing device of claim 6, wherein thememory and the processor are configured to adjust the length of therefresh timer for the next delay time period by being configured toincrease the refresh timer if at least a predetermined number of eventsare received during the current delay time period, or decrease therefresh timer if less than a predetermined number of events are receivedduring the delay time period.
 8. The computing device of claim 1,wherein the events are received asynchronously.
 9. A method comprising:receiving an event; controlling a refresh rate at which a user interfaceis refreshed to indicate receipt of the event using a refresh timer, alength of the refresh timer set based at least in part on a rate ofincoming events such that, when the rate of incoming events is low, therefresh timer length is decreased causing the refresh rate to beincreased, and when the rate of incoming events is high, the refreshtimer length is increased causing the refresh rate to be decreased; andrefreshing the user interface, in accordance with the refresh rate, todisplay one or more indications of the event.
 10. The method of claim 9,wherein the received event is received in a delay time period betweenexpiry of the refresh timer and a previous expiry of the refresh timer,and wherein refreshing the user interface further comprises refreshingthe user interface upon expiry of the refresh timer to display anindication of the event and one or more additional indications of one ormore additional events received during the delay time period.
 11. Themethod of claim 10, wherein the indication of the event indicatesreceipt of the event and one or more additional events received duringthe delay time period.
 12. The method of claim 9, further comprising:receiving an additional event; refreshing the user interface to displaythe indication of the event and the additional event responsive to therefresh timer expiring; and adjusting a length of the refresh timerbased on a duration of time between when the event and the additionalevent are received.
 13. The method of claim 9, further comprisingadjusting the length of the refresh timer based on a number of eventsreceived during a delay time period, the delay time period comprising aperiod between expiry of the refresh timer and a previous expiry of therefresh timer.
 14. The method of claim 13, wherein the adjusting furthercomprises increasing the length of the refresh timer if at least apredetermined number of events are received during the delay timeperiod.
 15. The method of claim 13, wherein the adjusting furthercomprises decreasing the length of the refresh timer if less than apredetermined number of events are received during the delay timeperiod.
 16. A method comprising: causing a user interface to bedisplayed; determining a current delay time period based upon a rate ofincoming events received in one or more previous delay time periods;receiving a plurality of events during the current delay time period;postponing the user interface from being refreshed to reflect theplurality of the events until the current delay time period has elapsed;and refreshing the user interface to display one or more indications ofthe plurality of events when the current delay time period elapses. 17.The method of claim 16, further comprising adjusting a length of a nextdelay time period based on a number of events received during thecurrent delay time period.
 18. The method of claim 17, wherein theadjusting further comprises: increasing the length of the next delaytime period relative to the current delay time period if at least apredetermined number of events are received during the current delaytime period; or decreasing the length of the next delay time periodrelative to the current delay time period if less than a predeterminednumber of events are received during the current delay time period. 19.The method of claim 16, wherein determining a current delay time periodbased upon a rate of incoming events received in one or more previousdelay time periods comprises determining the current delay time periodbased upon an average number of incoming events received in a pluralityof previous delay time periods.
 20. The method of claim 19, wherein theevents are communication events received over a communication network.